Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.1%. Comparing base (0975ce3) to head (64d7787).

@@               Coverage Diff               @@
##           enh/run-clone    #142     +/-   ##
===============================================
+ Coverage           87.1%   88.1%   +0.9%     
===============================================
  Files                231     231             
  Lines               8216    8125     -91     
===============================================
  Hits                7160    7160             
+ Misses              1056     965     -91     

Hmm, so what you are saying does check out. The ellipses is not really strictly required.

from typing import Protocol

class A(Protocol):
    def f(self):
        """This is a docstring"""
        ...

class B(A): ...

B().f()
# ^ Cannot instantiate abstract class "B" with abstract attribute "f"

And alike:

from typing import Protocol

class A(Protocol):
    def f(self):
        """This is a docstring"""

class B(A): ...

B().f()
# ^ Cannot instantiate abstract class "B" with abstract attribute "f"

However as soon as A.fcontains a yield or return the mypy error disappears, so it might be worth leaving these few lines so it doesnt happen accidentally.

I'm not sure I understand the problem with this. I created your example in the mypy playground, so please feel free to experiment with that.
The PR only removes ... from functions where this is the only "body" of the function. Whenever a function contains yield or return, it remains unchanged. There is no intersection of yield/return and ... in functions, it's either or. And the error is function-specific, as my playground example shows: B().f() doesn't work even if f() has a return statement if g() is abstract. So with or without the ellipses, one could only call the yield/return functions on child classes that actually provide implementations for the abstract functions.

Please let me know what I'm missing about this.